On the Internet, users actively access WWW servers from Web browsers, which are running on client terminals, to browse document data, image data, and the like on the client terminal side via the Web browsers. Each WWW server saves a document called a home page, which is prepared by describing information to be disclosed in HTML. The Web browser on the client terminal side accesses such home page and displays it on the display screen of a display device of the client terminal. Also, when the user designates a link in the home page displayed on the display device, the Web browser on the client terminal side can acquire required information by tracing a link destination indicated by the link.
Furthermore, as a method of downloading files managed by the WWW server, a method called “File Transfer Protocol” (to be abbreviated as “FTP” hereinafter) is known. The FTP is a scheme for transferring the contents of a file on the WWW server to the client computer at a time via a network.
As a protocol for fragmentarily accessing and displaying an image data file, Flashpix/IIP is known. This Internet imaging protocol (IIP) is optimal to the image data file format “Flashpix”, and makes partial access to image data for respective tiles of Flashpix. Some conventional techniques that use this IIP protocol have been disclosed (for example, see Japanese Patent Laid-Open No. 2002-49514).
With any of these protocols, data to be transmitted from the server are independent encoded data. For this reason, the server need not return data in consideration of the order of transmission data.
As a protocol for fragmentarily accessing and displaying a file encoded according to JPEG2000, JPEG2000 image coding system—Part 9: Interactivity tools, APIs and Protocols (to be abbreviated as JPIP hereinafter) has been examined. When JPEG2000 image data is fragmentarily transmitted to the client terminal using such protocol, the client terminal must cache received fragmentary encoded data in one file so as to decode the transmitted image data. This is because encoded data of each layer/level of JPEG2000 is difference data from data one layer/level lower than that layer/level.
The client that requests data using this JPIP can use the following two different requests in association with a return method of response data.
1) fullwindow: leaves the transmission order of response data to server's discretion, but requests to surely return all request data
2) progressive: allows to delete some request data, but requests to return data in the order of scalability in the image quality direction (layer progression order)
Therefore, when the client wants to surely receive all requested data, it issues the fullwindow request. Hence, the server returns data according to the server's implementation policy regardless of the process on the client side.
As described above, since the server returns JPEG2000 fragmentary data regardless of the order of transmission data, these data must be rearranged depending on the received data management method on the client terminal side.
When an image display application used on the client terminal side uses scalability in the resolution direction, and reads out received data in an order along the JPEG2000 bitstream syntax upon decoding, the received data must be managed after they are rearranged to be suited to display using resolution scalability, or data must be rearranged and read out.
In this way, rearranging received data upon management imposes a heavy load on the client terminal when received data are processed, and a long processing time is required every time the client terminal communicates with the server. When data are read out while being rearranged in a read order upon decoding, random access to saved data frequently occurs every time an image is displayed using already saved data, thus prolonging a time required until decoding, even when no communication is made.